home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 945 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.1 KB
  1. Path: kbad.eglin.af.mil!rpi!not-for-mail
  2. From: thp@cs.ucr.edu (Tom Payne)
  3. Newsgroups: comp.lang.c++.moderated,comp.lang.c++
  4. Subject: Re: Meaning of the specifier volatile?
  5. Date: 8 Jan 1996 15:49:29 -0000
  6. Organization: University of California, Riverside Department of Computer Science
  7. Sender: cppmods@netlab.cs.rpi.edu
  8. Approved: Dietmar.Kuehl@uni-konstanz.de
  9. Message-ID: <4cree9$9bv@netlab.cs.rpi.edu>
  10. References: <4c9740$27n@netlab.cs.rpi.edu> <4cff74$gfj@netlab.cs.rpi.edu> <4cj5u4$qjm@netlab.cs.rpi.edu>
  11. NNTP-Posting-Host: netlab.cs.rpi.edu
  12.  
  13. X-Original-Date: 6 Jan 1996 21:57:16 GMT
  14.  
  15. J. Kanze (kanze@gabi-soft.fr) wrote:
  16. [stuff deleted]
  17. : On point concerning volatile that I have not seen made is the fact that
  18. : the C/C++ concept of volatile is orthogonal to atomicity of access.
  19. : Declaring an object volatile is *NOT* sufficient with regards to
  20. : asynchronous events; the object must still be of a type for which the
  21. : compiler will generate atomic accesses.  
  22. [stuff deleted]
  23.  
  24. Because of the signal-handlers-can't-read provision of the ANSI C
  25. standard, atomicity is unnecessary in the coordination of asynchronous
  26. activity for programs with defined behavior:
  27.  
  28.   *  signal handlers won't read any partially written non-atomic 
  29.      shared variables, because they are not allowed to read variables 
  30.      of static storage class in programs with defined behavior.
  31.  
  32.   *  the program itself won't read any partially written non-atomic 
  33.      shared varible, because signal handlers don't return control 
  34.      until they have completed their writes of volatile variables.
  35.  
  36. With pre-emptive multithreading, of course, the possibility of
  37. pre-emption during a non-atomic write requires atomicity of some
  38. coordination variables, but it's impossible to introduce
  39. multithreading and stay within defined behavior per the ANSI 
  40. standard.
  41.  
  42. Tom Payne (thp@cs.ucr.edu)
  43.  
  44.     [ comp.lang.c++.moderated is a moderated newsgroup.  Submit articles ]
  45.     [  to <c++-submit@netlab.cs.rpi.edu>.  The moderation policy can be  ]
  46.     [   retrieved from <http://netlab.cs.rpi.edu/~cppmods/guide.html>.   ]
  47.     [    Moderators can be reached at: c++-request@netlab.cs.rpi.edu.    ]
  48.